Der Befehl arp-scan -l führt eine ARP-Anfrage im lokalen Netzwerk aus. Wir erhalten die IP-Adresse (192.168.2.113) und die MAC-Adresse (08:00:27:86:a5:c8) des Zielsystems. Die Information "PCS Systemtechnik GmbH" deutet auf den Hersteller der Netzwerkkarte hin.
**Empfehlung:** Das Filtern von ARP-Anfragen kann das Aufspüren von Geräten im Netzwerk erschweren.
Der Befehl nmap -sV -p- 192.168.2.113 führt einen umfassenden Portscan auf dem Zielsystem durch und versucht, die Versionen der laufenden Dienste zu identifizieren. Wir stellen fest:
**Empfehlung:** Beschränken Sie den Zugriff auf das ".git"-Verzeichnis, um sensible Informationen nicht preiszugeben.
Nach der grundlegenden Aufklärung konzentrieren wir uns auf die Webanwendungen, die auf dem Zielsystem laufen. Wir nutzen verschiedene Tools, um versteckte Dateien und Verzeichnisse zu finden und die Angriffsfläche zu vergrößern.
nikto -h 192.168.2.113 ist ein Tool, das Webserver auf bekannte Schwachstellen untersucht. Nikto identifiziert mehrere interessante Punkte:
**Empfehlung:** Konfigurieren Sie die fehlenden Sicherheitsheader und aktualisieren Sie die Apache-Version. Beschränken Sie den Zugriff auf sensible Dateien.
gobuster dir -u http://192.168.2.113/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt verwendet eine Wordlist, um versteckte Verzeichnisse auf dem Webserver zu finden.
Interessante Ergebnisse sind:
**Empfehlung:** Überprüfen Sie die Konfiguration des Webservers, um sicherzustellen, dass keine sensiblen Verzeichnisse öffentlich zugänglich sind.
In diesem Abschnitt versuchen wir, einen ersten Zugang zum System zu erlangen. Wir analysieren die gesammelten Informationen, um mögliche Schwachstellen zu identifizieren und auszunutzen.
JWT Token Entschlüsselung
Validierung des JWT-Tokens auf https://jwt.io/
https://jwt.io/Hier wird versucht, ein JWT (JSON Web Token) zu entschlüsseln, das möglicherweise sensible Informationen enthält. Die Ausgabe "Data is not a valid byteArray" deutet darauf hin, dass die Entschlüsselung fehlgeschlagen ist oder der Token ungültig ist.
**Empfehlung:** Validieren und sichern Sie JWTs korrekt, um Manipulationen und unbefugten Zugriff zu verhindern.
whatweb http://192.168.2.113/ -v identifiziert die verwendete Technologie auf der Webseite.
Wir erhalten Informationen wie:
**Empfehlung:** Entfernen Sie unnötige Informationen aus den Meta-Tags und schützen Sie die E-Mail-Adressen vor Spam.
Ein Versuch, sich auf der Gitea-Instanz (Port 8585) mit dem Benutzernamen "frank" anzumelden, schlägt fehl. Dies deutet darauf hin, dass wir entweder den Benutzernamen oder das Passwort falsch haben.
**Empfehlung:** Führen Sie eine Passwort-Recovery durch oder versuchen Sie, das Passwort zu erraten/bruteforcen.
Das Anzeigen des Quellcodes von "http://192.168.2.113:8585/debug/profile/" gibt uns die Gitea Version (1.12.5) und einen CSRF-Token. Diese Informationen könnten für weitere Angriffe nützlich sein.
**Empfehlung:** Deaktivieren Sie Debug-Funktionen in Produktionsumgebungen, um sensible Informationen nicht preiszugeben.
Der Versuch, das Git-Repository auf Port 8585 mit git-dumper zu dumpen, schlägt fehl, da die HEAD-Datei nicht gefunden wurde (404-Fehler).
Dies könnte bedeuten, dass das Repository nicht korrekt konfiguriert ist oder der Zugriff eingeschränkt ist.
**Empfehlung:** Überprüfen Sie die Konfiguration des Git-Repositorys und stellen Sie sicher, dass es korrekt eingerichtet ist.
Ein weiterer Versuch, das Git-Repository auf Port 8585 zu dumpen, schlägt erneut fehl. Der gleiche Fehler deutet auf ein Problem mit der Konfiguration des Repositorys oder den Zugriffsrechten hin.
**Empfehlung:** Untersuchen Sie die Git-Repository-Konfiguration und stellen Sie sicher, dass die erforderlichen Dateien vorhanden und zugänglich sind.
Hier wird versucht, sich mit einer SQL-Injection auf der Backend-Login-Seite anzumelden. Der Payload "admin' R 1=1 -- -" ist ein gängiger SQL-Injection-Versuch, der darauf abzielt, die Authentifizierung zu umgehen.
**Empfehlung:** Implementieren Sie geeignete Schutzmaßnahmen gegen SQL-Injections, wie z.B. parametrisierte Abfragen oder Input-Validierung.
Die Fehlermeldung "A user was not found with the given credentials" deutet darauf hin, dass die SQL-Injection nicht erfolgreich war oder dass der Benutzer "admin" nicht existiert.
**Empfehlung:** Überprüfen Sie die Benutzerverwaltung und stellen Sie sicher, dass Standardbenutzer wie "admin" entweder umbenannt oder entfernt werden.
Google Suche nach einer möglichen Schwachstelle
https://www.google.de/search?q=gitea+version+1.12.5+exploit&sc....Eine Google-Suche nach "gitea version 1.12.5 exploit" führt zu einem Exploit auf Exploit-DB, der eine Remote Code Execution (RCE) ermöglicht. Dies ist ein vielversprechender Ansatz, um Zugriff auf das System zu erhalten.
**Empfehlung:** Patchen Sie die Gitea-Installation auf die neueste Version, um bekannte Sicherheitslücken zu schließen.
Hier wird das Git-Repository unter "http://192.168.2.113/.git" mit dem git-dumper Tool gedumpt.
Im Gegensatz zu den vorherigen Versuchen auf Port 8585 ist dieser Versuch erfolgreich.
Dies deutet darauf hin, dass das Repository auf Port 80 zugänglich ist.
**Empfehlung:** Beschränken Sie den Zugriff auf das ".git"-Verzeichnis unbedingt, um sensible Informationen nicht preiszugeben.
Nach dem Dumpen des Repositorys wird das Verzeichnis "dev" erstellt, das die heruntergeladenen Dateien enthält.
**Empfehlung:** Überprüfen Sie regelmäßig die Integrität Ihrer Dateisysteme und stellen Sie sicher, dass keine unerwarteten Verzeichnisse oder Dateien vorhanden sind.
Das Auflisten des Inhalts des "dev"-Verzeichnisses zeigt, dass es sich um eine PHP-Anwendung handelt. Besonders interessant sind "adminer.php" (ein Web-basiertes Datenbankverwaltungstool) und das "config"-Verzeichnis (das Konfigurationsdateien enthält).
**Empfehlung:** Entfernen Sie "adminer.php" aus der Produktionsumgebung, da es ein potenzielles Sicherheitsrisiko darstellt. Sichern Sie die Konfigurationsdateien, um unbefugten Zugriff zu verhindern.
Das Auslesen der "database.php"-Datei offenbart die Datenbank-Zugangsdaten:
**Empfehlung:** Sichern Sie die Datenbank-Zugangsdaten und verwenden Sie starke Passwörter. Beschränken Sie den Zugriff auf die Datenbank auf autorisierte Benutzer.
Mit den gefundenen Datenbank-Zugangsdaten können wir uns erfolgreich in Adminer einloggen. Wir haben nun Zugriff auf alle Daten in der "octoberdb"-Datenbank.
**Empfehlung:** Entfernen Sie Adminer aus der Produktionsumgebung. Sichern Sie die Datenbank und beschränken Sie den Zugriff darauf.
Der Versuch, eine PHP-Datei mit einer SQL-Injection über Adminer zu erstellen, schlägt fehl. Der Fehler "Access denied" deutet darauf hin, dass der Benutzer "october" nicht die erforderlichen Rechte hat, um Dateien zu schreiben.
**Empfehlung:** Beschränken Sie die Rechte von Datenbankbenutzern auf das unbedingt Notwendige.
Dieser Proof of Concept demonstriert, wie eine Schwachstelle in der Template-Engine des Content-Management-Systems ausgenutzt werden kann, um Remote Code Execution (RCE) zu erreichen.
Ziel ist es, beliebigen Code auf dem Server auszuführen, indem eine unsichere Template-Funktion im CMS ausgenutzt wird.
Zuerst loggen wir uns mit den bekannten Zugangsdaten (frank:benni) in das Backend des CMS ein.
Wir navigieren zum Bereich, in dem Templates bearbeitet werden können. Dies ist oft unter "CMS" oder "Design" zu finden.
Wir erstellen ein neues Template oder bearbeiten ein bestehendes, um unseren Payload einzufügen.
Wir fügen den folgenden Payload in das Template ein:
Wir speichern das Template.
Wir rufen die Seite auf, die das Template verwendet, um den Payload auszuführen.
Durch die Ausnutzung der unsicheren Template-Funktion wird beliebiger Code auf dem Server ausgeführt. Im Idealfall erhalten wir eine Shell oder können anderweitig das System kompromittieren.
Ein Screenshot der ausgeführten Shell oder ein anderer Beweis für die erfolgreiche Codeausführung sollte hier eingefügt werden.
Die Ausnutzung dieser Schwachstelle ermöglicht es Angreifern, die vollständige Kontrolle über den Server zu übernehmen. Dies kann zu Datenverlust, Kompromittierung von Benutzerdaten und anderen schwerwiegenden Schäden führen.
eval() oder system() zulässt.Hier werden die Datenbank-Zugangsdaten verwendet, um im CMS-Backend als Administrator einzusteigen.
Nachdem wir uns im Backend des CMS angemeldet haben, suchen wir nach Möglichkeiten, um Befehle auszuführen.
Der Code "system($\_GET['cmd']);" ermöglicht es uns, beliebige Befehle über die URL auszuführen. Dies ist eine schwerwiegende Sicherheitslücke.
**Empfehlung:** Vermeiden Sie die Verwendung von unsicheren Funktionen wie "system()" in Produktionsumgebungen. Implementieren Sie eine sichere Methode, um Befehle auszuführen, falls dies erforderlich ist.
Die Funktion "shell_exec($\_GET['cmd']);" ermöglicht es uns, beliebige Befehle über die URL auszuführen. Dies ist eine schwerwiegende Sicherheitslücke.
**Empfehlung:** Vermeiden Sie die Verwendung von unsicheren Funktionen wie "shell_exec()" in Produktionsumgebungen. Implementieren Sie eine sichere Methode, um Befehle auszuführen, falls dies erforderlich ist.
Der Befehl "ls" wird erfolgreich über die URL ausgeführt. Wir können nun beliebige Befehle auf dem Server ausführen.
**Empfehlung:** Validieren Sie die Eingabe des Benutzers, bevor Sie sie an "shell_exec()" oder andere Befehlsausführungsfunktionen übergeben.
Wir starten einen Netcat-Listener auf Port 9001, um eine Reverse-Shell zu empfangen.
**Empfehlung:** Verwenden Sie starke Passwörter und beschränken Sie den Zugriff auf das System auf autorisierte Benutzer.
Wir erhalten eine Reverse-Shell als "www-data"-Benutzer.
**Empfehlung:** Führen Sie Anwendungen mit dem geringstmöglichen Berechtigungsniveau aus.
Nachdem wir eine Shell als "www-data"-Benutzer erhalten haben, versuchen wir, unsere Privilegien zu erhöhen, um Root-Zugriff zu erhalten.
Der Befehl find / -type f -perm -4000 -ls 2>/dev/null sucht nach Dateien mit dem SUID-Bit gesetzt.
SUID-Binaries können potenziell ausgenutzt werden, um Privilegien zu erhöhen.
In diesem Fall ist /usr/bin/pkexec ein interessanter Kandidat.
**Empfehlung:** Überprüfen Sie regelmäßig die SUID-Binaries auf Ihrem System und stellen Sie sicher, dass sie sicher konfiguriert sind.
Es wird geprüft, ob curl installiert ist, da es später für den Download von Exploits benötigt wird.
Es wird in das /tmp/ Verzeichnis gewechselt, um dort Dateien abzulegen und auszuführen.
Die Ausführung des PwnKit Exploits war erfolgreich, wir sind jetzt als `root` angemeldet.
**Empfehlung:** Patchen Sie Systeme schnellstmöglich, um bekannte Schwachstellen zu beheben.
Die User Flag wurde gefunden und ausgegeben.
Die Root Flag wurde gefunden und ausgegeben.
Fantastisch! Der Root-Zugriff war erfolgreich. Wir haben unser Ziel erreicht. Nun haben wir alle Flags erhalten und das System erfolgreich kompromittiert.
Wir beginnen mit der Aufklärung (Reconnaissance), um Informationen über das Zielsystem zu sammeln. Dies ist ein entscheidender Schritt, um potenzielle Angriffspunkte zu identifizieren.